Provisioning is an important aspect in getting the network ready to serve the end users. It normally involves provisioning of multiple parameters, multiple nodes and the provisioning system needs to keep the data consistent.
A typical provisioning system works like the following:
A CSO (Customer Service Order) is sent from business support systems of the operator to the provisioning system. A CSO normally contains a bunch of parameters that can get one or more NEs (Network Elements) ready to support a certain service and enable the subscriber to use said service. Such a CSO would need to be provisioned into the network, where it might end up with provisioning of multiple NEs (Network Elements), with multiple request/response communications towards each of them.
In such a provisioning sequence it is very important to keep the completeness or consistency of the data, both within the same node or across multiple NEs, since the incompleteness and inconsistency of the data will result in the incapability of implementing the service. These are typical cases:                Part of the subscriber data resides in multiple NEs and they need to be exactly the same, or they are related. These data is either in all places or they should be in some of them.        In case of only one NE is provisioned, there might be multiple requests sent and each with part of the data. The business support systems would like to have the whole CSO completed.        
The traditional solutions for the completeness/consistency problem include:                Retrying by storing the uncompleted commands, i.e. the uncompleted part of the CSO. If a command fails in the middle, typically due to the NE is not available because of e.g. link failure, the command that failed together with all the ones following that will be stored in a queue to be executed later.        Rollback previous commands. The commands that have been successfully executed which impacts the consistency of the subscriber data will be rolled back, to remove inconsistency.        
However, said existing solutions are both problematic. A CSO might end up with multiple commands towards one or more NEs. The generation of the commands might be dependent on the status of NE itself. For example you need to do a “Read” command to read the status of the NE from the NE before you know how to generate and execute the next “Modify” command. This means that the generation very often needs to be done by some logic/code dynamically not static.
Then for the retrying approach above by storing the not executed commands, it would need to predict for the commands that are left upon the failure. This is very often not possible to be done successfully, especially in scenarios with a complex logic or when interactions (e.g. read) with NE is mandatory.
Rollback tries to solve the inconsistency immediately, compared with retry approach by trying to fix it later, by undoing what has been successfully done and reverting to the previous state. The problems with this one is the rollback scenarios might be many, especially for a complex logic, and rollback can fail too probably where the CSO has just failed, then you will get stuck. For example, if a “create subscriber” command fails and the subsequent rollback also fails in the middle, then you can't move forward by either trying to create again (because part of it already exists and creating a new one with the existing part remaining will result in inconsistence) or delete (because part of it has not been created yet, the delete won't succeed).